Good, pragmatic approach to reducing the flakiness of XsltFromFileExceptionTest.

What works well:

• The dedicated XSL file (example-file-exception-test.xsl) isolates this test from the ~16 other tests that reference example.xsl, eliminating potential resource contention through JAXP's TransformerFactory caching layer
• The new file is an exact copy of example.xsl — no behavioral change to the test logic
• The PR description is honest about scope: this targets the 2nd/3rd retry failures (the JAXP0801003 operator-limit error), not necessarily the first failure mode

Minor observation (non-blocking): The JAXP0801003 error about XPath operator limits (accumulated '2' operators exceeds the '1' limit set by 'system property') could also stem from another test setting jdk.xml.xpathExprOpLimit via System.setProperty without restoring it. File isolation helps with TransformerFactory cache contention but wouldn't fix a JVM-wide system property leak. Worth investigating separately if the flakiness persists after this change.

Overall, a sensible incremental fix — reduces the blast radius without over-engineering it. 👍

Claude Code on behalf of gnodet — AI-generated review

Updating my earlier review after investigating the root cause of the flakiness.

Root cause: system property leak from ZXsltTotalOpsTest

The JAXP error in the 2nd/3rd retries —

JAXP0801003: the compiler encountered XPath expressions with an accumulated '2'
operators that exceeds the '1' limit set by 'system property'.

— is caused by ZXsltTotalOpsTest (same package) leaking jdk.xml.xpathTotalOpLimit=1 via System.setProperty.

Here's the chain:

1. ZXsltTotalOpsTest calls xslt.setXpathTotalOpLimit(1), which triggers System.setProperty("jdk.xml.xpathTotalOpLimit", "1") during XsltComponent.doInit()
2. The test expects context.start() to throw (the XSL has 2 operators > limit of 1)
3. Cleanup relies on XsltComponent.doShutdown() calling System.clearProperty() — but when context.start() fails mid-way, the shutdown path may not fully execute
4. When XsltFromFileExceptionTest retries (after its 1st failure for a different reason), the leaked property causes any XSL compilation with >1 operator to fail

This matches your observation exactly: the 1st failure has a different cause, then ZXsltTotalOpsTest runs during the retry window, leaks the property, and retries 2 and 3 hit the JAXP limit.

Why a dedicated XSL file won't fix this

The new example-file-exception-test.xsl has 2 XPath operators (match="/" + select="/hello") — identical to example.xsl. When jdk.xml.xpathTotalOpLimit=1 is leaked, any XSL file with >1 operator fails regardless of its path. File isolation addresses TransformerFactory cache contention, but the error is a JVM-wide system property issue.

Suggested fix

Ensure ZXsltTotalOpsTest cleans up the system property reliably, similar to how XPathFeatureTest handles it (with @ResourceLock(Resources.SYSTEM_PROPERTIES) + try/finally):

@Isolated
@ResourceLock(Resources.SYSTEM_PROPERTIES)
public class ZXsltTotalOpsTest extends ContextTestSupport {

    @AfterEach
    void clearXpathLimit() {
        System.clearProperty("jdk.xml.xpathTotalOpLimit");
    }
    // ... rest unchanged
}

Adding @AfterEach guarantees the property is cleared even when context.start() throws and the CamelContext lifecycle doesn't fully unwind. The @ResourceLock annotation prevents other system-property-sensitive tests from running concurrently.

Claude Code on behalf of gnodet — AI-generated review

Claude Code on behalf of gnodet

LGTM — thanks for addressing the review feedback!

The updated approach is exactly right: the @AfterEach cleanup on ZXsltTotalOpsTest ensures jdk.xml.xpathTotalOpLimit is cleared even when context.start() throws and the CamelContext lifecycle doesn't fully unwind. This fixes the root cause (system property leak) rather than working around it with file isolation.

One optional follow-up: adding @ResourceLock(Resources.SYSTEM_PROPERTIES) (from JUnit 5 parallel execution) would additionally prevent concurrent test runs from racing on the system property. Not a blocker for this PR though.

The @AfterEach cleanup prevents the leak — nice and simple. However, the test mutates system properties via System.setProperty("jdk.xml.xpathTotalOpLimit", ...) (inside XsltComponent.setXpathTotalOpLimit(1)), so it should also declare a write-mode @ResourceLock:

import org.junit.jupiter.api.parallel.ResourceLock;
import org.junit.jupiter.api.parallel.Resources;

@Isolated
@ResourceLock(Resources.SYSTEM_PROPERTIES)
public class ZXsltTotalOpsTest extends ContextTestSupport {

Why: TestSupport (the grandparent) declares @ResourceLock(value = Resources.SYSTEM_PROPERTIES, mode = READ), telling JUnit this test only reads system properties. Since this test writes them, the inherited declaration is incorrect — it should be overridden with the default (READ_WRITE) mode.

@Isolated already prevents concurrent execution, so this is not a functional bug today, but it's defense in depth and makes the contract explicit.